Applying design-metrics to object-oriented frameworks

We present a novel way of using object oriented design metrics as to support for the incremental development of object oriented programs. Based on a quality model (factor-criteria-metrics model), so-called multi-metrics relate a number of simple structural measurements to design principles and rules. Single components of an object oriented program like classes or subsystems are analyzed to determine whether they conform to specific design goals. Concise measurement reports together with detailed explanations of the obtained values identify problem spots in system design and give hints for improvement. This allows the designer to measure and evaluate programs at an appropriate level of abstraction. This paper details the use of the multi-metrics approach for the design and improvement of a framework for industry and used for graphical applications. Multimetrics tools were used with several versions of the framework. The measurement results were used in design reviews to quantify the effects of efforts to reorganize the framework. The results showed that this approach was very effective at giving good feedback, even to very experienced software developers. It helped them to improve their software and to create stable system designs. 1. Software development using metrics Different measurements are important tools for achieving quality management in the software development process. Two major measurement types are product metrics which are used to control the quality of the software product (e.g. defect rates) or process metrics which are used to measure the status and progress of the system design process and to predict future effects or problem areas (e.g. maintenance costs). Traditionally, product metrics are applied to incomplete software products in order to measure their complexity and to predict properties of the final product, like the estimated amount of testing necessary or the total development costs [9]. Examples of this type of metrics application are given by McCabe [20] and Halstead [14] for structured programs and in [19] for object oriented systems. Metrics may be defined for program code as well as for documents on the design level as documented by Card [5]. The primary object for most metrics applications is to allow managers to trace the project status, to achieve high product quality, and to simplify the planning processes. A different approach is to use measurement as an integral part of the design process to assist software developers in improving their product quality. A major question is which criteria make it possible to measure positive and negative elements of systems design and how to use such measurement results to improve the design process [cf. 12]. The application of simple product metrics to entire programs, like measuring the average module interface size of a system, can only indicate certain problems but does not relate measurement results back to design principles. It can be very difficult for the developer to decide on the right action to take upon receipt of a particular metrics value. Design metrics improve this situation by relating knowledge about good design (design rules or design heuristics) to characteristic structural system properties (cf. [11] and [3]). Most object oriented metrics deal with structural properties like the depth of inheritance trees. Therefore, we find metrics mostly on the design level. Examples are Chidamber and Kemerer's 'metric suite' [6] and Abbott, Korson et al.'s 'design complexity metric' [1]. The use of such design metrics as part of the development process has two problems. First, complex metrics are often used, i.e. metrics that combine several simple metrics into one formula. The measurements produced by a complex metric are very difficult to relate back to particular properties of the system under consideration. Often it is hard to trace backwards to the constituent of the formula which is responsible for the produced value and how to improve it. An example of such a complex metrics is 'interaction level' metrics proposed in [1]. Secondly, for most design metrics no criteria or thresholds are given to judge whether a value indicates a critical situation that needs improvement. This makes the interpretation of measurement results rather difficult. The approach presented in this paper avoids the first problem by using only simple metrics together with appropriate strategies for getting a similar level of abstraction as achieved by complex metrics. Furthermore, we propose a systematic approach for defining applicationspecific thresholds and interpreting measurement values using trend analysis. This opens the door for a tight coupling of the software development steps and the usage of a metrics tool; the design-rules reflecting particular quality goals of the developer are an integral part of the metrics tool. The tool is used to assess the software. It interprets metric values and transforms them into statements at about the level of abstraction expressed in design-rules. In addition, it supports the designer in localizing problem spots by providing explanations of each value. Thus the software engineer gets direct assistance in applying particular design rules which improve the structure of his software. Figure 1 sketches a sample software development process using such feedback from design metrics. In section 2, we describe the development process of object-oriented frameworks. Section 3 contains the new methodological aspects necessary for the application of design-rules to software. In section 4, we present a case study which shows the results of applying the method to an object-oriented framework. 2 Developing object-oriented frameworks Object-oriented frameworks are, generally speaking, object-oriented software. They use object-oriented concepts like abstraction, encapsulation, classes and objects, inheritance, and polymorphism to create well-integrated sets of cooperating components to be used as stable kernel for a family of applications ([4], [8], [15]). Frameworks differ from common object-oriented software in their level of abstraction and how they are used: The development process of object-oriented frameworks is highly iterative. Continuous monitoring and improvement of their design is essential because of their long-term use. The method proposed in this paper is particularly well suited for this type of framework development. The primary goal of frameworks is to be reused in as many applications as possible with as few changes as possible [10]. Reusability is achieved in that the framework generalizes concepts from a range of similar applications making it a corresponding abstract application. The application of object-oriented design-principles like modularity, abstraction, and de-coupling ("good design") lead to better maintainability and reusability. However, the object-oriented paradigm alone does not guarantee good design. Developers have to understand designprinciples and to check whether those have been obeyed. Therefore, framework development needs experienced software engineers. Frameworks never achieve a perfect form in their initial design or after only a few iterations. Development proceeds iteratively and evolutionary. A continuously enhanced program gets more and more complex, its inner structure more and more disorderly, unless countermeasures are taken to consolidate its design. Therefore, every phase of functional extension is Fig. 1 Ideal process: developers can assess the conformance to design rules, by design-metrics giving immediate feedback when design rules have been violated. quality goals apply Coupling: class X : outlier class Y: outlier -> decouple! metrics tool ! design rules narrow interfaces loose coupling